QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940062.txt

Internet Message Format | 1994-11-13 | 15KB

Date: Tue,  8 Mar 94 04:30:22 PST
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #62
To: Ham-Digital


Ham-Digital Digest          Tue,  8 Mar 94       Volume 94 : Issue   62

Today's Topics:
                     Anyone have the AX.25 spec?
                      Comercial Data Over Radio
                 Food For Thought -- The BBS Network
                           Help Mac->PK232
                           IMPORTANT NOTICE
   megabit per second packet  (was "Re: Packet at 1.2 GHz (23cm)?")
                                 test
                  want aresdata pgm info for packet

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 2 Mar 94 20:37:43 GMT
From: agate!howland.reston.ans.net!gatech!swrinde!sgiblab!wetware!spunky.RedBrick.COM!psinntp!psinntp!arrl.org![e-mail]
Subject: Anyone have the AX.25 spec?
To: [e-mail]

Brian Mahaffy ([e-mail]) wrote:
: Does anyone have the AX.25 spec they could email me.  I have looked
: in several places on the Internet, but could not find it.

The AX.25 specification is available on the ARRL's Automated Email
Information Server ([e-mail]).  To receive this information, send
an email to [e-mail] with any subject and the following text as the
body of your message:

help
index
send ax25-1.doc
send ax25-2.doc
quit

You will receive a short set of instructions, a list of available
information and the ax.25 spec (in two parts).  Additional information on
the information server will be posted later this week.

73 de Michael Tracy, KC1SX, ARRL Technical Information Services


------------------------------

Date: 7 Mar 94 20:38:50 GMT
From: [e-mail]
Subject: Comercial Data Over Radio
To: [e-mail]

                       Subject:                               Time:2:05 PM
  OFFICE MEMO          Comercial Data Over Radio              Date:3/7/94
In reply to: need ssb packet radio info from
netcomsv!netcomsv!majiq![e-mail]

The author wrote "I want to use marine ssb to transfer files between 2
vessels.  Each vessel would be equiped with a PC, radio modem, software and
SSB transceiver.  I am looking for recommendations on how to get this to
work.  This would be for commercial use..."

The folks who manufacture ham TNC's/modems probably do more business with
commercial customers than with hams.  So, I'd recommend contacting them
directly.  Examples are:  HAL Communications, P.O. Box 365, Urbana, IL 61801;
Kantronics Corp., 1202 E. 23rd St., Lawrence, KS 66046; PacComm, 4413 N.
Hesperides St., Tampa, FL 33614; to name a few.  If you've got the big bucks
there is always Harris, et al, too!

By the way, unless you have a special circumstance (read high S/N, low
multipath channel) such as line of sight, I'd stay away from AX.25 on H F.
It would be hard to devise a worse protocol for H.F., even if you tried.
Look at PacTOR, CLOVER II, etc., in "ham" hardware.

73/Rick W0TN <[e-mail]>

P.S. -- I'd prefer to answer by e-mail, but you didn't put name and info in
your request for info.

------------------------------

Date: 7 Mar 1994 08:40:53 -0600
From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu![e-mail]
Subject: Food For Thought -- The BBS Network
To: [e-mail]

Here are a few observations on improvements needed to the BBS network.  I
hope that this generates some discussion of these problems which will lead
to solutions.

BBSs have no priority mechanism for distingushing between bulk mail
(bulletins, etc.), normal mail and priority or emergency mail. In an
emergency environment these distinctions must be made and the messages
queued appropriately. There should be a mechanism to forward priority or
emergency mail immediately and to limit the rate of or suspend the
forwarding of normal mail and bulk mail.  Priority designators should be
compatible with or mappable to NTS designators and any other applicable
designators; the mapping should be well defined.  This capability should
be added to the BBS software and should be controllable by remote sysops.

There is a schism between the SMTP (TCP/IP) addressing and the BBS
addressing mechanism: neither form is compatible with the other.
Additionally, some forms of the BBS addresses look too much like Internet
addresses (for example, NA and SA are valid Internet top-level domains).
This makes it difficult for systems running both BBS and TCP/IP to handle
mail.  The creation of an addressing system which is compatible with the
Internet (and with OSI?) addressing should be explored; if compatiblity is
unobtainable the BBS addressing system should at least coexist with little
confusion and operational difficulties.

Personal messages (one-to-one) and bulletins (one-to-many) are too
interemixed.  There should be a separation of these two functions at the
protocol and addressing level, even if they are combined at the user
interface.

Bulletins are nearly impossible to manage, especially if one tries to
organize them in some logical fashion.  Standardized names for bulletin
groups should be established with allowances for the addition of local and
regional groups.  MIDs, BIDs, and other IDs need to be clarified and
possibly simplified.  BIDs should be expanded to be compatible with that
used on the Internet so that newsgroups can be gatewayed at multiple
points while avoiding duplication of bulletins.

BBS message interchange protocols are poorly documented.  (This is being
worked on by W0RLI and others.)

Jeff, k9ja
+-+
Jeffrey Austen       |  Tennessee Technological University
[e-mail]   |  Box 5004
[phone]       |  Cookeville Tennessee 38505   U.S.A.

------------------------------

Date: 7 Mar 94 13:40:46 -0500
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!darwin.sura.net!atlas.tntech.edu![e-mail]
Subject: Help Mac->PK232
To: [e-mail]

Hi,

would appreciate some help. Trying to help a new ham in town. He just
purchased an older PK232 and is interested in Packet. He has a Macintosh
computer. Does anyone know of any software out there that is shareware/
freeware that is good?

thanks

Jeff, AC4HF

------------------------------

Date: 2 Mar 94 13:20:10 GMT
From: agate!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!paris.ics.uci.edu!news.claremont.edu!kaiwan.com!wetware!spunky.RedBrick.COM!psinntp!psinntp!laidbak!tellab5!jwa@
Subject: IMPORTANT NOTICE
To: [e-mail]

3-2-94

CORRECTIONS

In the March 94 issue of QST "Packet Perspective"  Stan Horzepa
WA1LOU wrote an article about the Hamblaster.

I would like to make this correction

The Address should have been

Jack Albert  (WA9FVP)
203 York Pl.
New Lenox, Il
60451

Ph  (815)-723-6564


The address in my signature file (below) is my work QTH.

Tellabs Operations Inc. does not manufacture and
is not involved with the research and development
of the Hamblaster.



All inquires should be sent to the address above.

---

   Jack Albert  WA9FVP             Fellow Radio Hacker
                     Tele [phone]
   Tellabs Operations, Inc.     FAX  [phone]
   1000 Remington Blvd.         [e-mail]
   Bolingbrook, IL  60440

------------------------------

Date: 4 Mar 94 04:42:00 GMT
From: dog.ee.lbl.gov!agate!library.ucla.edu!news.mic.ucla.edu!MVS.OAC.UCLA.EDU![e-mail]
Subject: megabit per second packet  (was "Re: Packet at 1.2 GHz (23cm)?")
To: [e-mail]

What about 97.311 part e?

"The station records must document all SS emission transmissions
and must be retained for a period of 1 year..."  This includes a
general description of the data being sent...

Yuck.  Makes me want to go part 15 instead...

------------------------------

Date: 7 Mar 94 16:20:21 MDT
From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!utah-morgan!hellgate.utah.edu!cc.usu.edu!stevec.cs.usu.edu![e-mail]
Subject: test
To: [e-mail]



------------------------------

Date: 7 Mar 1994 08:54:00 -0800
From: ihnp4.ucsd.edu!swrinde!gatech!udel!news.sprintlink.net!connected.com!connected.com![e-mail]
Subject: want aresdata pgm info for packet
To: [e-mail]

Within one of the several help screens for arespack at the very last two lines
you will find the authors of DATA - one is Weo Morner, San Jose, 408 997 3195.
I dont remember if he is visible by doing a function key or shift function key
but certainly is if you read the help files outside of the program with say,
the type command.

John
--
John Gates                      |  Amateur Radio: N7BTI
Edmonds, WA  USA                |  Internet:      [e-mail]
206 774-3777                    |  Compuserve:    72106,367

------------------------------

Date: 2 Mar 94 16:44:32 GMT
From: agate!howland.reston.ans.net!cs.utexas.edu!asuvax!pitstop.mcd.mot.com!mcdphx!schbbs!waters.corp.mot.com.corp.mot.com![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>π
Subject : Re: Using packet radio to access an internet account...

In article <[e-mail]>, [e-mail]
(Gary Coffman) wrote:

> In article <[e-mail]> [e-mail] (Mike Waters) writes:

> Obscenity is in the eye of the beholder as the Supreme Court has repeatedly
> ruled. Thus the "community standards" tests required for something to be
> declared obscene. Simple profanity is no longer illegal in any state.
> Vulgarity is haphazardly regulated in different jurisdictions, but always
> *only in public*. Private communications containing profanity, vulgarity,
> and even obscenity are protected speech as long as both parties to the
> conversation consent. "Obscene" phone calls are really a misnomer. What's
> covered under these statutes is more appropriately called *harassing* phone
> calls where one party is an unwilling participant.

I don't want to do a Westlaw search on this, but in the last round of the
pornography hysteria there have been a whole bunch of regulkations issued
about "indecent" speech.  Not tested in court as far as I know, but (IMHO)
the really objectionable part is an attempt to extend this to private
telephone conversations.

This subject is often debated on soc.motss since these laws are often used
to harass homosexuals in various ways. Sorry I don't have any more specific
references to cite right now.

> The FCC has ruled that broadcast radio transmissions, including amateur,
> but *not* common carrier, are always considered *public* utterances with
> possible "unwilling" listeners. Thus the prohibitions against utterances
> that are offensive to the listener community are justified. The FCC has
> issued guidance in the form of the "7 deadly words" that must never be
> uttered over the airwaves, and following Supreme Court guidance, the FCC
> has also prohibited speech referring to excretory or sexual practices.
> There are no corresponding limitations on point to point common carrier
> content.

This indeed was the rule until circa 1991.

> Common carrier and
> voluntary private conversations and correspondence fall under the
> area of protected speech. Public utterances and writings fall under
> varying sets of restrictions  depending on where, when, and how they
> are made. The FCC's "broadcast" interpretation is the strictest of
> these limits.

Those who would protect our tender ears from such things delight in
pointing out that the first amendment is not absolute and that truly
"protected speed" only applies to "legitimate" political debate.  In
practice this often means subjects approved by those in power. For example
the "man boy love association" and the harrassment they have received for
trying to voice their views.  (Not that I think they have merit, but they
are supposed to have the right to expressthose views).

I really don't want to get into a Libertarian debate here, I will leave
that to those who have a burning interest in suchthings (see my .sig - I
really mean it :-)

--
Phooey on it all - I'm going sailing for a year or two!!!

------------------------------

Date: 2 Mar 94 16:52:53 GMT
From: agate!howland.reston.ans.net!gatech!asuvax!pitstop.mcd.mot.com!mcdphx!schbbs!waters.corp.mot.com.corp.mot.com![e-mail]
To: [e-mail]

References <[e-mail]>, <2l0qv9$[e-mail]>, <[e-mail]>
Subject : Re: megabit per second packet  (was "Re: Packet at 1.2 GHz (23cm)?")

In article <[e-mail]>, [e-mail]
(Gary Coffman) wrote:


> (1) Only the following sets of connections may be used:
>
> Number of stages    Taps used
> in the shift register    in feedback
>
> 7            7,1
> 13            13,4,3,1
> 19            19,5,2,1
[...]
> Well, whomp there it is! Clear as mud isn't it?

What the rules don't make clear is that shift registers in various
combinations can generate some interesting sequences which don't repeat for
a very long time.  The ones allowed by the rules are "short sequence" codes
which repeat fairly often, thus it is not difficult (comparitively
speaking) for the FCC to find and monitor the transmission.

Last time I studied the question (>15 years ago :-), the publically
available theory wasn't very helpfull in predicting the lengths of the
sequences and their "randomness".  Still an interesting area for
"tinkering".

--
Phooey on it all - I'm going sailing for a year or two!!!

------------------------------

End of Ham-Digital Digest V94 #62
******************************